System for encoding customer data

ABSTRACT

A system for encoding customer data includes a memory, a decision engine, a rules engine and an interface engine. The memory stores customer data associated with service levels and rules. The decision engine receives a request for customer data from a third party, determines that the third party is associated with a first service level, and retrieves the customer data associated with the first service level. The rules engine transforms customer data into first and second code segments by applying the rules. The rules engine combines at least the first code segment and the second code segment to form a customer profile code. An interface engine communicates the customer profile code to the third party.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 14/849,626, filed Sep. 10, 2015 and entitled, “System forEncoding Customer Data,” which is a continuation of U.S. patentapplication Ser. No. 14/518,076, filed Oct. 20, 2014 which is now U.S.Pat. No. 9,159,069 issued Oct. 13, 2015 and entitled “System forEncoding Customer Data.”

TECHNICAL FIELD

This invention relates generally to analyzing and communicating data,and more particularly to encoding customer data.

BACKGROUND

Enterprises assemble vast amounts of customer data. In conventionalsystems, enterprises communicate uncoded customer data in accordancewith a customer identifier, such as a customer account number. This isproblematic because uncoded data is susceptible to security breaches anduncoded data uses a substantial amount of resources, such as bandwidthand memory.

SUMMARY OF EXAMPLE EMBODIMENTS

According to embodiments of the present disclosure, disadvantages andproblems associated with communicating customer data may be reduced oreliminated.

In accordance with a particular embodiment of the present disclosure, arules engine stores a first rule, a second rule, and customer data,wherein the customer data is associated with a particular customer. Therules engine transforms a portion of the customer data into a first codesegment by applying a first rule and transforms a portion of thecustomer data into a second code segment by applying a second rule. Inaddition, the rules engine combines at least the first code segment andthe second code segment to form a customer profile code. The customerprofile code is associated with a customer identifier. A decision enginecommunicatively coupled to the rules engine stores third party data,wherein the third party data is associated with a request for customerinformation. The decision engine determines whether the customeridentifier of the customer profile code matches the third party data,and an interface engine communicatively coupled to the decision enginecommunicates the customer profile code to a third party if the customeridentifier of the customer profile code and the third party data match.

Certain embodiments of the present disclosure may provide one or moretechnical advantages. A technical advantage of one embodiment includessaving resources such as bandwidth and memory by consolidating largeamounts of customer data within an enterprise into a centralized unitand transforming that data, on a customer by customer basis, into aunique customer profile code. As another example, a technical advantageof one embodiment includes mitigating data breaches by communicatingsecured customer data to third parties via a customer profile code. Anda further technical advantage of an embodiment includes conveniently,efficiently, and securely transferring customer data to third parties bysharing an enterprise's encoded customer profile code with a third partyvia a secure application programming interface (API). As a finalexample, a technical advantage of one embodiment includes providinggreater efficiencies for computer resources and network usage.

Other technical advantages of the present disclosure will be readilyapparent to one skilled in the art from the following figures,descriptions, and claims. Moreover, while specific advantages have beenenumerated above, various embodiments may include all, some, or none ofthe enumerated advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and forfurther features and advantages thereof, reference is now made to thefollowing description taken in conjunction with the accompanyingdrawings, in which:

FIG. 1 illustrates an example embodiment of a system for encodingcustomer data;

FIG. 2 illustrates a block diagram of an example system for encodingcustomer data;

FIG. 3 illustrates an example embodiment of a method for encodingcustomer data;

FIG. 4 illustrates an example embodiment of a method for encodingcustomer data according to service levels;

FIG. 5 illustrates an example embodiment of a method for decodingcustomer data to authenticate a customer;

FIG. 6 illustrates an example embodiment of a method for decodingcustomer data to analyze a geographical area; and

FIG. 7 illustrates an example embodiment of a method for decodingcustomer data to determine an operations history for a set of customers.

DETAILED DESCRIPTION

Embodiments of the present invention and its advantages are bestunderstood by referring to FIGS. 1-7, like numerals being used for likeand corresponding parts of the various drawings.

Enterprises are organizations and typically include business units,divisions, or lines of businesses that handle the trade of various goodsand services within the enterprise. Services may include, but are notlimited to, transforming customer data into customer profile codes sothat it can be efficiently and securely shared with third parties.Services may further include, but are not limited to, transformingcustomer profile codes back into customer data after it has beensecurely received by third parties.

To facilitate providing encoded customer data, enterprises maycommunicate encoded customer profile codes to third parties vianetworks. Typically, enterprises store customer data according to acustomer identifier, such as a customer account number. The teachings ofthis disclosure recognize that it would be desirable to provide a rulesengine that transforms the customer data into code segments and combinesthe code segments to form a customer profile code, thus creating asnapshot of the customer data. The teachings of this disclosure alsorecognize that it would be desirable to provide a decision engine thatcommunicates a customer profile code to a third party if the customeridentifier associated with the customer profile code matches third partydata. Further, the teachings of this disclosure recognize that when acustomer identifier of a customer profile code matches third party data,it would be desirable to communicate the rules and the code segments toa third party to enable the third party to decode the customer profilecode. The teachings of this disclosure further recognize that a thirdparty may receive the code segments and transform them back into thecustomer data by applying rules communicated by the enterprise.

As such, the teachings of this disclosure provide for greaterefficiencies in computer resources and network usage. For example, bytransforming vast amounts of customer data into compressed customerprofile codes, less resources such as bandwidth and memory are requiredto store the customer data and to communicate the customer data bothinternally within the enterprise and externally to third parties.Further, the teachings of this disclosure provide for greater securityof an enterprise's customer data. For instance, by encoding the customerdata, the enterprise reduces the risk of third parties gaining access toits customer data without the enterprise's consent.

FIG. 1 illustrates a system for encoding customer data. Morespecifically, system 100 includes rules engine 110, decision engine 150,and interface engine 170. Generally, rules engine 110, decision engine150, and interface engine 170 interact to efficiently analyze,transform, and communicate customer data.

In the illustrated embodiment of FIG. 1, rules engine 110 storescustomer data 112, first rule 120 a, and second rule 120 b. Customerdata 112 a-112 n represents the data of a particular customer 114,wherein n represents any suitable number. Customer data 112 may includedescriptive data such as, for example, customer 114's demographic data(e.g., age, gender, ethnicity), spoken languages, employment data (e.g.,employment status, employer, employment history, direct depositinformation), life cycle events (e.g., retirement, having a child,buying a house, sending child to college), geographic data (e.g., travelhistory, location of residence, location of customer upon occurrence ofvarious events), medical information (e.g., medical payment history,patient status, medication purchases, hospital or doctor visits, healthinformation), educational information (e.g., degrees, tuition, loans,class schedules), and financial information (e.g., income, investments,trades, options, contracts, margins, portfolios, account information).Further, customer data 112 may include behavioral data, or generalpatterns exhibited by customer 114 when using certain products orservices. For example, behavioral data may include customer 114'sshopping habits (e.g., purchasing, browsing, and registering activities,merchant/customer data, SKU level data for items purchased), bankaccount activities, loan and mortgage commitments, and operationsinformation. Behavioral data may also include, for instance, thefrequency in which customer 114 visits an institution or call center,customer 114's inquiries at an institution or call center, and customer114's recorded conversations with an associate of an enterprise.Customer data 112 is not limited to descriptive and behavioral data andcan include any data associated with customer 114.

In addition, customer data 112 may comprise one or more customeridentifiers 116. Customer identifier 116 is any identifier associatedwith customer 114 that differentiates customer 114 from other customersof an enterprise. For example, customer identifier 116 may be a phonenumber, an email address, biometric information (e.g., voice scan,retina scan, fingerprint, facial recognition, and the like), or anaccount number of customer 114. In some embodiments, customer identifier116 may include customer 114's physical address or customer 114'sdriver's license number. Customer identifier 116 can be any datasuitable to identify customer 114. Customer identifier 116 may also beassociated with any of the following: a user device identifier (e.g.,computer MAC address, mobile identification number, mobile subscriptionidentification number, International Mobile Station Equipment Identityor IMEI, or the like); student identification number; account number;card number; dynamic token; social media profile or token; or any otherunique or semi-unique identifying information.

In one embodiment, customer data 112 is associated with service levels113 a-n. The different service levels 113 may determine what level ofaccess to customer data 112 a particular third party is entitled toreceive. For example, some customer data 112 may be associated with oneservice level 113—such as a lower tier of service—and other customerdata 112 may be associated with another service level 113—such as ahigher tier of service. The different tiers of service levels 113 maythen be associated with particular third parties that may request accessto the customer data 112. Thus, a particular third party that pays ahigher price, enjoys a trusted status with the enterprise, or otherwisemaintains a higher status may be entitled to more, different, orenhanced customer data 112 associated with a higher service level 113.In contrast, another third party that may pay a lower price, have a lesstrusted or untrusted status with the enterprise, or otherwise maintainsa lower status may be entitled to less or basic customer data 112associated with a lower service level 113. Alternatively or in addition,third parties in different industries may get access to differentcustomer data 112 and service levels 113. Third parties can subscribewith the enterprise to gain access to the customer data 112 as a part ofan on-boarding process. During this on-boarding process, the thirdparties can subscribe to a particular service level 113 for a particularsubscription fee.

Rules 120 a-120 n of rules engine 110 include any parameters forclassifying customer data 112. For example, rules 120 may facilitateclassification of customer data 112 in accordance with any of thevariety of customer data described above, such as for example, customer114's income, transactional history, credit rating, or date of birth.Rules 120 a-120 n may be created or managed by devices, persons, or anyother suitable source. For example, associates may write specific rulesfor third party 162. As another example, software may be used to evolverules 120 a-120 n over time based on patterns shown by system 100.

Rules engine 110 of system 100 also includes first rule 120 a as shownin FIG. 1 of the illustrated embodiment. First rule 120 a may includeone or more conditions 122 a-122 n, wherein n represents any suitablenumber. First rule 120 a may also include one or more code segments 126a-126 n, wherein n represents any suitable number. In some embodiments,conditions 122 a-122 n are associated with code segments 126 a-126 n.For example, condition 122 f may be associated with code segment 126 f.In the illustrated embodiment of FIG. 1, conditions 122 a, 122 b, and122 c are associated with income brackets. Customer data 112 g mayrepresent customer 114's income. As such, if customer income data 112 gfalls below $25,000 annually, then rules engine 110 transforms 112 ginto code segment 126 a, which is represented by “X1” in FIG. 1.Similarly, if customer income data 112 g falls at or between $25,000 and$50,000 annually, then rules engine 110 transforms customer income data112 g into code segment 126 b, represented by “X2”. And if customerincome data 112 g is above $50,000 annually, then rules engine 110transforms customer income data 112 g into code segment 126 c,represented by “X3”. For example, if customer income data 112 g is$15,000 annually, then rules engine 110 transforms customer income data112 g into code segment “X1”, as shown in the illustrated embodiment ofFIG. 1.

Though only one condition is satisfied in the illustrated embodiment ofFIG. 1, more than one condition may be satisfied in other embodiments,or no condition may be satisfied, depending on the parameters ofcustomer data 112. Further, in some embodiments, first rule 120 aincludes less than three conditions. Alternatively, first rule 120 a mayinclude more than three conditions, for example ten conditions. Further,conditions 122 a, 122 b, and 122 c may be associated with more than onetype of customer data. For example, condition 122 a may be associatedwith customer 114's income whereas conditions 122 b and 122 c areassociated with customer 114's quantity of purchases within a givenperiod of time. Moreover, different rules 120 and conditions 122 may beused in conjunction with the specific service levels 113 described aboveand with reference to FIG. 4, customer authentication requests describedwith reference to FIG. 5, geographical areas described with reference toFIG. 6, and customer operations history described with reference to FIG.7. The rules 120 and conditions 122 used in those embodiments may dependon the particular request for customer data 112 or the particularretrieved customer data 112.

In some embodiments, rules engine 110 of system 100 further comprisessecond rule 120 b. Second rule 120 b may include one or more conditions132 a-132 n, wherein n represents any suitable number. Second rule 120 bmay also include one or more code segments 136 a-136 n, wherein nrepresents any suitable number. In some embodiments, conditions 132a-132 n are associated with code segments 136 a-136 n. For example,condition 132 g may be associated with code segment 136 g. In theillustrated embodiment of FIG. 1, conditions 132 a, 132 b, and 132 c areassociated with birth year brackets. Customer data 112 h may representcustomer 114's birth year. As such, if birth year customer data 112 hfalls at or between the years “1940” and “1959”, then rules engine 110transforms customer data 112 h into code segment 132 a, represented by“Y1”. Similarly, if birth year customer data 112 h falls at or betweenthe years “1960” and “1979”, then rules engine 110 transforms customerdata 112 h into code segment 132 b, represented by “Y2”. And if birthyear customer data 112 h falls at or between the years “1980” and“1999”, then the rules engine transforms customer data 112 h into codesegment 132 c, represented by “Y3”. For example, if birth year customerdata 112 h is the year “1967”, then rules engine 110 transforms customerbirth year data 112 h into code segment “Y2”, as shown in theillustrated embodiment of FIG. 1.

While first rule 120 a includes three conditions 122 a, 122 b, and 122c, and second rule 120 b includes three conditions 132 a, 132 b, and 132c in the illustrated embodiment of FIG. 1, rules engine 110 of system100 may include more or less than two rules, and each rule may includemore or less than three conditions. For example, rules engine 110 maycomprise 1,000 rules, wherein each rule includes 100 conditions. Asanother example, rules engine 110 may comprise a first rule with fiveconditions, a second rule with 100 conditions, and a third rule with onecondition. Conditions 122 a-122 n and 132 a-132 n may be associated withmore than one type of customer data 112. For example, condition 122 amay be associated with customer 114's birth year, condition 122 b may beassociated with customer 114's purchases, and condition 122 c may beassociated with customer 114's income. Further, while rules 120 a and120 b in the illustrated embodiment include conditions, rules 120 a-120n may instead or in addition include any suitable information for use inthe operation of rules engine 110.

In some embodiments, rules engine 110 of system 100 transforms at leasta portion of customer data 112 a-112 n into a customer profile code 140based on at least a combination of code segments 126 a-126 n and 136a-136 n. For example, as shown in the illustrated embodiment of FIG. 1,rules engine 110 concatenates code segment 126 a, represented by “X1”,and code segment 136 b, represented by “Y2”, to generate customerprofile code 140, represented by “X1Y2”. In some instances, rules engine110 may concatenate more than two code segments to generate customerprofile code 140, for example “X1Y2Z3”. Rules engine 110 may transformcustomer data 112 a-112 n in any manner suitable for compressing orsecuring customer data 112 a-112 n. For example, transforming customerdata 112 a-112 n may include encoding, encrypting, or hashing customerdata 112 a-112 n.

While rules engine 110 in the illustrated embodiment of FIG. 1concatenates code segments 126 a and 136 b to form customer profile code140, rules engine 110 may transform code segments 126 a-126 n and 136a-136 n in any manner suitable for coding data. For instance, codesegments 126 a (“X1”) and 136 b (“Y2”) may jointly be represented byalphanumeric characters “A1”, by the number “10”, or by a symbol, suchas a triangle. Further, customer profile code 140 may utilize any codingsystem suitable to protect against the unauthorized use of customer140's information. For example, customer profile code 140 may be analphanumeric code, as shown in the illustrated embodiment of FIG. 1. Asanother example, customer profile code may be a binary code. Rulesengine 110 may generate customer profile codes 140 for multiplecustomers 114 a-114 n.

Some customer profile codes 140 may be more sophisticated than othercustomer profile codes 140. For instance, a customer with a large amountof customer data 112 may have a more sophisticated customer profile code140 than a customer with a less amount of customer data 112. Further, insome embodiments customer profile code 140 is associated with customeridentifier 116. Customer identifier 116 may be located within customerdata 112 a-112 n and can be any data that differentiates customer 114from other customers of enterprise 210. For example, customer identifier116 may be customer 114's social security number, customer 114's bankaccount number, or customer 114's email address.

Rules engine 110 of system 100 may apply rules 120 a-120 n to customerdata 112 on a periodic or continuous basis to generate customer profilecode 140. For example, rules engine 110 may generate customer profilecode 140 periodically by applying rules 120 a-120 n to customer data 112once every minute, once a week, or three times a week. As anotherexample, rules engine 110 may apply rules 120 a-120 n to customer data112 in real time so that the customer profile code 140 is always basedon the most recent customer data 112 a-112 n. In some embodiments, rulesengine 110 may only apply certain rules to the exclusion of others togenerate customer profile code 140. Similarly, rules engine 110 may onlyapply certain conditions to the exclusion of others to generate customerprofile code 140.

System 100 as shown in the illustrated embodiment of FIG. 1 alsoincludes decision engine 150. Decision engine 150 is communicativelycoupled to rules engine 110 and is operable to store third party data160 associated with a request for customer information. Third party data160 is information that can be used to identify customer 114 ofenterprise 210, such as an email address, a telephone number, a socialsecurity number, or a bank account number. Decision engine 150 may alsostore customer data 112 a-112 n, customer identifiers 116 a-116 n, or aportion thereof.

Decision engine 150 is further operable to determine whether customeridentifier 116 of customer profile code 140 matches third party data160. For example, if customer identifier 116 is represented by phonenumber 555-0102, and third party data 160 is represented by phone number555-0102, then decision engine 150 verifies a match between customeridentifier 116 and third party data 160. In some embodiments, decisionengine 150 may determine whether third party data 160 matches more thanone customer identifier 116 a-116 n. For instance, system 100 mayrequire that two pieces of third party data, for example 160 a and 160b, match two customer identifiers, for example 116 a and 116 b. In someembodiments, decision engine 150 may determine a confidence score 117based on the number and type of customer identifiers 116 that matchthird party data 160. For example, if a suitable number (e.g., 3) ofcustomer identifiers 116 match third party data 160; or if highlytrusted types of customer identifiers 116 (e.g., biometric data;collection of biographic of unique information) matches third party data160; or any suitable combination of number of type of customeridentifiers 116 match third party data 160, then decision engine 150 mayregister a higher confidence score 117. If the confidence score 117meets or exceeds a predetermined customer identifier threshold 118, thendecision engine 150 determines a match. If the confidence score 117falls below the threshold 118, then decision engine 150 determines amismatch. The level of threshold 118 can be set (e.g., high, low ormedium) depending on the type of customer data 112 requested (e.g.,higher threshold 118 for more sensitive customer data 112), the servicelevel 113 of the third party requesting the customer data 112 (e.g.,lower threshold for third party with high service level 113), theparticular customer 114, or any suitable number and combination of theforegoing.

Decision engine 150 is further operable to determine what customer data112 a particular third party is entitled to based on service levels 113.For example, a third party that enjoys a high service level 113 with theenterprise may be entitled to a particular portion of customer data 112,while a third party that enjoys a lower service level 113 with theenterprise may be entitled to a different portion of customer data 112.As described above, the service level 113 associated with a particularthird party may be determined according to the third party'ssubscription with the enterprise as established during an on-boardingprocess. The third party's subscription can also be terminated as partof an off-boarding process and the terminated third party would nolonger have access to customer data 112 in that situation. In responseto a request for customer data 112 from a third party, decision engine150 determines the identity and service level 113 of the third party andretrieves the appropriate customer data 112 according to the determinedservice level 113 for that third party.

System 100 of the illustrated embodiment of FIG. 1 also includes aninterface engine 170. Interface engine 170 is communicatively coupled todecision engine 150 and operable to communicate customer profile code140 to third party 162 if customer identifier 116 of customer profilecode 140 matches third party data 160. Third party 162 can be any partyexternal to enterprise 210 that can benefit from receiving customerinformation that has been transformed into code segments based onconditions such as income and birth year. Examples of third parties 162include merchants, health care organizations, credit card companies,financial institutions, e-commerce sites, social media sites, orfinancial sites such as financial planning websites. In addition, thirdparty 162 may be a realty site or an aggregator.

Interface engine 170 of system 100 may be further operable tocommunicate rules 120 a-120 n, conditions, 122 a-122 n and 132 a-132 n,and code segments 126 a-126 n and 136 a-136 n to third party 162 tofacilitate decoding of customer profile code 140. For example, ifcustomer identifier 116 of customer profile code 140 matches third partydata 160, interface engine 170 may communicate first rule 120 a andsecond rule 120 b to third party 160. Further, if customer identifier114 of customer profile code 140 matches third party data 160, interfaceengine 170 may communicate the code segments associated with thesatisfied conditions to third party 162 to enable third party 162 todecode customer profile code 140. As such, in accordance with theillustrated embodiment of FIG. 1, third party 162 can utilize codesegment 126 a (“X1”) to associate third party data 160 with an incomeless than $25,000 annually. Similarly, third party 162 can utilize codesegment 136 b (“Y2”) to associate third party data 160 with a date ofbirth between the years 1960 and 1979.

Interface engine 170 of system 100 may operate as an applicationprogramming interface (API). As such, interface engine 170 maycommunicate customer profile code 140 to third party 162 by grantingthird party 162 access to customer profile code 140 via the API. Inaddition, interface engine 170 may communicate rules 120 a-120 n,conditions, 122 a-122 n and 132 a-132 n, and code segments 126 a-126 nand 136 a-136 n to third party 162 by granting third party 162 access tothe API. By utilizing a secure API, an enterprise can efficiently andconveniently share customer profile codes and other information operableto decode the customer profile codes with third parties.

Transforming customer data 112 into customer profile codes 140 leads togreater efficiencies of system 100. Because customer profile codes 140represent compressed versions of customer data 112, they can be storedusing less memory and communicated using less bandwidth. Further,customer profile codes 140 are less susceptible to breach since they areencoded. And because customer profile codes 140 represent satisfiedconditions rather than specific customer data 112 a-112 n, customer data112 a-112 n of enterprise 210 remains protected.

Modifications, additions, or omissions may be made to system 100 withoutdeparting from the scope of the invention. For example, system 100 mayinclude any number of rules engines 110, decision engines 150, andinterface engines 170. As another example, decision module 150 mayrequest third party data 160 from an external module. Furthermore, thecomponents of system 100 may be integrated or separated. For example,rules engine 110 and decision engine 150 may be incorporated into asingle component. In another example, decision engine 150 and interfaceengine 170 may be incorporated into a single component.

FIG. 2 illustrates a system for encoding customer data. Morespecifically, system 200 includes enterprise 210, assembly module 220,rules engine 110, decision engine 150, and external module 250.Generally, assembly module 220, rules engine 110, and decision engine150 interact to efficiently assemble, analyze, and communicate data.Assembly module 220, rules engine 110, and decision 150 may be locatedinternal or external to enterprise 210. Assembly module 220, rulesengine 110, decision engine 150, external module 250, and othercomponents within system 200 may be communicatively coupled by network260.

In the illustrated embodiment of FIG. 2, assembly module 220 comprisesinterface 222, processor 224, and memory 226. Memory 226 of assemblymodule 220 includes customer data sources 228 a-228 n, wherein nrepresents any suitable number. Customer data sources 228 a-228 n may beassociated with customer 114 and may include customer data 112 a-112 n,such as demographic and behavioral data of customer 114.

In one embodiment, as described in greater detail below with respect toFIG. 5, customer data 112 may be associated with a particular customer114 to be authenticated by a third party. In this embodiment, a thirdparty may seek to authenticate a particular customer. For example, amerchant, a bank, or a credit card company may be trying to determinewhether to offer a credit card to a customer and, if so, how big of acredit line to associate with the credit card. In this example, thethird party requests customer data 112 (e.g., annual salary, employmentstatus, monthly deposits into account; interruptions to automaticdeposit; annual spend; etc.) for this particular customer 114 to informits decision of whether and how much credit to offer to the customer 114based on the received customer data 112. In another example, a thirdparty may be attempting to verify the identity of a particular customer114 with whom it is interacting. In this example, the third partyrequests customer identification information from the customer andcustomer data 112 (e.g., demographic information; account information;other identifying data) from the enterprise. If the customeridentification information from the customer matches the customer data112 received from the enterprise, then the customer's identity isverified. Each of these examples is generally referred to asauthenticating a customer 114. The customer data 112 provided in eitheror both of the above examples can fall into a specific range (e.g.,annual salary of customer 114 is between $50,000 and $99,999) or be aspecific value or statement (e.g., customer 114 is unemployed).

In another embodiment, as described in greater detail below with respectto FIG. 6, customer data 112 may be associated with one or morecustomers 114 in a particular geographical region, such as in aparticular one or more cities or zip codes. In this embodiment, thecustomer data 112 may be associated with particular customers 114 in thegeographic region, may be aggregated for all customers 114 in thegeographic region, or may be aggregated for a subset of customers 114 inthe geographic region where that subset of customers 114 share certaincommon characteristics (e.g., common demographic information or commonbehavioral information). A third party that requests this customer data112 specific to a particular geographic area may then use it to analyzethe potential of providing goods and services in that geographical area.In one embodiment, a third party merchant may use this information todetermine which additional geographic markets it should or should notenter, or which targeted goods or services to offer in a particularexisting geographic market.

For example, a high-end grocery chain can request and analyze customerdata 112 to determine the shopping habits and trends of its targeteddemographic customers 114 in a particular city or zip code to determinewhether or not to open a new store in that geographical area. In anotherexample, the high-end grocery chain may analyze customer data 112 todetermine that it should market and sell more or less of a particulargood or service in a particular one of its stores based on the shoppinghabits or trends of its targeted demographic customers 114 in thatgeographical area. In still another example, a healthcare organizationmay request and analyze the medical payment history or medicationpurchase information for a targeted demographic of customers 114 todetermine whether or not to open a doctor's office or offer particularhealth goods or services (e.g., using SKU level data) in a particulargeographical area. The healthcare company can also use customer data 114to set up their business in a new geographic area by determining theircompetitors' pricing structure in that area. These examples arenon-limiting and provided to explain the underlying methodology for howcustomer data 112 can be used to analyze opportunities in a particulargeographic area.

In still another embodiment, as described in greater detail below withrespect to FIG. 7, customer data 112 may be associated with a particularset of customers 114 associated with a particular third party. Forexample, a third party merchant may seek information for a set of itsexisting customers or a set of potential customers for its goods andservices. This third party merchant may then use the customer data 112for these customers 114 to determine their operations history (e.g.,where that set of customers 114 spends money to purchase goods andservices; how much money that set of customers 114 spends on goods andservices elsewhere; the frequency of spending for that set of customers;etc.). The third party merchant can then use this information to targetthose locations for its own sales and marketing. In one embodiment, if afirst merchant determines that its customers are spending a lot of moneypurchasing goods and services at a second merchant (whether online orbrick and mortar), then that first merchant can target its marketingactivities in conjunction with the second merchant, and vice versa.

For example, a high-end grocery chain can use customer data 112 todetermine that its existing or potential customers 114 are spendingtheir disposable income at nearby golf courses and movie theaters, andpurchasing gas at particular gas stations. The grocery chain can analyzethis customer data 112 to then perform targeted marketing (e.g.,advertising, coupons, joint promotions and the like) in those placeswhere its existing or potential customers are otherwise spending theirmoney. In these examples, the customer data 112 may be aggregated over asubset of customers 114 sharing particular demographic information orother characteristics. These examples are non-limiting and provided toexplain the underlying methodology for how customer data 112 can be usedto determine an operations history for customers 114, which includeswhere the customer 114 spends money, how much, how frequently, and otherassociated trends.

Customer data sources 228 a-228 n of assembly module 220 represent anysources of information that may be used by assembly module 220 and/orcomponents of enterprise 210. Customer data sources 228 a-228 n mayinclude a device (such as a database, a personal computer, aworkstation, a laptop, a wireless or cellular telephone, an electronicnotebook, a personal digital assistant, or any other device capable ofreceiving, processing, storing, and/or communicating information), aperson (such as a person who has knowledge of an entity and who providessuch knowledge for communication to assembly module 220), any othersuitable source of information, or any combination of the preceding. Incertain embodiments, assembly module 220 may receive information fromcustomer data sources 228 a-228 n to communicate to rules engine 110 anddecision engine 150. Customer data sources 228 a-228 n may be located inenterprise 210 or any other location that allows for customer datasources 228 a-228 n to communicate via network 260.

Assembly module 220 may include a network service, any suitable remoteservice, a mainframe, a host computer, a workstation, a web server, apersonal computer, a file server, or any other suitable device operableto communicate with enterprise 210. In some embodiments, assembly module220 may execute any suitable operating system such as IBM'szSeries/Operating System (z/OS), MS-DOS, PC-DOS, MAC-OS, WINDOWS, UNIX,OpenVMS, or any other appropriate operating systems, including futureoperating systems. The functions of assembly module 220 may be performedby any suitable combination of one or more servers or other componentsat one or more locations. In the embodiment where the modules areservers, the servers may be public or private servers, and each servermay be a virtual or physical server. The server may include one or moreservers at the same or at remote locations. Also, assembly module 220may include any suitable component that functions as a server.

System 200 of the illustrated embodiment of FIG. 2 also includes rulesengine 110, which is communicatively coupled to assembly module 220.Rules engine 110 may include interface 232, processor 234, and memory236. In the illustrated embodiment, memory 236 includes customer data112 a-112 n, rules 120 a-120 n, and customer profile codes 140 a-140 n.System 200 of the illustrated embodiment of FIG. 2 further includesdecision engine 150. Decision engine 150 is communicatively coupled torules engine 110 and may comprise interface 242, processor 244, andmemory 246. In the illustrated embodiment, memory 246 includes customerdata 112 a-112 n and third party data 160 a-160 n. In addition, system200 comprises external module 250, as shown in the illustratedembodiment of FIG. 2. External module 250 includes third party data 160a-160 n.

Network 260 facilitates communications between enterprise 210, assemblymodule 220, rules engine 110, decision engine 150, and external module250. This disclosure contemplates any suitable network 260 operable tofacilitate communication between the components of system 200. Network260 may include any interconnecting system capable of transmittingaudio, video, signals, data, messages, or any combination of thepreceding. Network 260 may include all or a portion of a public switchedtelephone network (PSTN), a public or private data network, a local areanetwork (LAN), a metropolitan area network (MAN), a wide area network(WAN), a local, regional, or global communication or computer network,such as the Internet, a wireline or wireless network, an enterpriseintranet, or any other suitable communication link, includingcombinations thereof, operable to facilitate communication between thecomponents. This disclosure contemplates end networks having one or moreof the described properties of network 260.

System 200 includes one or more interfaces. For example, the illustratedembodiment of FIG. 2 includes interface 222 for assembly module 220,interface 232 for rules engine 110, and interface 242 for decisionengine 150. Interfaces 222, 232, and 242 represent any suitable deviceoperable to receive information from network 260, transmit informationthrough network 260, perform suitable processing of the information,communicate to other devices, or any combination of the preceding. Forexample, interface 222 of assembly module 220 transmits customer data112 a-112 n to rules engine 110, and interface 232 of rules engine 110receives customer data from interface 222. As another example, interface242 of decision engine 150 may receive third party data 160 fromexternal module 250 and may communicate customer profile code 140 toexternal module 250 if customer identifier 116 matches third party data160. Interfaces 222, 232, and 242 represent any port or connection, realor virtual, including any suitable hardware and/or software, includingprotocol conversion and data processing capabilities, to communicatethrough a LAN, WAN, or other communication system that allows enterprise210 to exchange information between assembly module 220, rules engine110, decision engine 150, external module 250, network 260, and othercomponents of system 200.

In addition, system 200 includes one or more processors. For example,the illustrated embodiment of FIG. 2 includes processor 224 for assemblymodule 220, processor 234 for rules engine 110, and processor 244 fordecision engine 150. Processors 224, 234, and 244 control the operationand administration of enterprise 210 by processing information receivedfrom interfaces 222, 232, and 242. As such, processors 224, 234, and 244are communicatively coupled to interfaces 222, 232, 242, respectively.Processors 224, 234, 244, and 254 include any hardware and/or softwarethat operates to control and process information. For example, processor234 utilizes rules 120 a-120 n to control the operation of rules engine110. Processor 224, 234, or 244 may be a programmable logic device, amicrocontroller, a microprocessor, any suitable processing device, orany suitable combination of the preceding.

System 200 further includes one or more memories. For example, theillustrated embodiment of FIG. 2 includes memory 226 for assembly module220, memory 236 for rules engine 110, and memory 246 for decision engine150. Memory 226, 236, or 246 may represent a database that stores,either permanently or temporarily, customer data 112 a-112 n or rules120 a-120 n. Memory 226, 236, or 246 includes any one or a combinationof volatile or non-volatile local or remote devices suitable for storinginformation. For example, memory 226, 236, or 246 may include RandomAccess Memory (“RAM”), Read-only Memory (“ROM”), magnetic storagedevices, optical storage devices, or any other suitable informationstorage device or a combination of these devices. Memory 226, 236, or246 may include any suitable information for use in the operation ofenterprise 210. Additionally, memory 226, 236, or 246 may be a componentexternal to enterprise 210 and may be situated in any location suitablefor memory to communicate to the other modules of system 200. Assemblymodule 220, rules engine 110, and decision engine 150 can each containmore than one memory component.

Memory 226, 236, or 246 may include one or more rules 120 a-120 n. Rules120 a-120 n generally refer to logic, rules, algorithms, code, tables,and/or other suitable instructions embodied in a computer-readablestorage medium for performing the described functions and operations ofsystem 200. For example, rules 120 a-120 n may facilitate thetransformation of a portion of customer data 112 a-112 n into codesegments 126 a-126 n.

System 200 may include one or more computers. A computer may be anydevice that interacts with system 200. A computer may use a processorand a memory to execute an application in order to perform any of thefunctions described herein. A computer may be a personal computer, aworkstation, a laptop, a wireless or cellular telephone, an electronicnotebook, a personal digital assistant, a tablet, or any other device(wireless, wireline, or otherwise) capable of receiving, processing,storing, and/or communicating information with other components ofsystem 200. A computer may also include a user interface, such as adisplay, a touchscreen, a microphone, keypad, or other appropriateterminal equipment usable by a user.

A component of system 200 may include an interface, logic, memory,and/or other suitable element. An interface receives input, sendsoutput, processes the input and/or output, and/or performs othersuitable operations. An interface may comprise hardware and/or software.Logic performs the operations of the component. For example, logicexecutes instructions to generate output from input. Logic may includehardware, software, and/or other logic. Logic may be encoded in one ormore non-transitory, tangible media, such as a computer readable storagemedium or any other suitable tangible medium, and may perform operationswhen executed by a computer. Certain logic, such as a processor, maymanage the operation of a component. Examples of a processor include oneor more computers, one or more microprocessors, one or moreapplications, and/or other logic.

Modifications, additions, or omissions may be made to system 200 withoutdeparting from the scope of the invention. For example, system 200 mayinclude any number of assembly modules 220, rules engines 110, decisionengines 150, and external modules 250. As another example, decisionmodule 150 may communicate a request for third party data 160 fromexternal module 250. Furthermore, the components of system 200 may beintegrated or separated. For example, assembly module 220 and rulesengine 110 may be incorporated into a single component. In anotherexample, rules engine 110 and decision engine 150 may be incorporatedinto a single component.

FIG. 3 illustrates an example method for encoding customer data. Themethod begins at step 310 when interface of rules engine 110 receivescustomer data 112 a-112 n from data sources 228 a-228 n. At step 312,rules engine 110 applies rules 120 a-120 n to transform a portion ofcustomer data 112 a-112 n into one or more data segments. For example,rules engine 110 may apply rule 120 a to transform a portion of customerdata 112 a-112 n into code segment “X1”. As another example, rulesengine 110 may apply rule 120 b to transform a portion of customer data112 a-112 n into code segment “Y2”. Rules engine 110 may update rules120 a-120 n periodically or continuously. At step 314, rules engine 110generates customer profile code 140 based on the one or more datasegments, for example “X1Y2”. Customer profile code 140 is associatedwith at least one customer identifier 116. Customer identifier 116 maybe a social security number, bank account number, or any otherinformation that will identify customer 114 from the list of customersof enterprise 210. Rules engine 110 may update customer profile code 140continuously or periodically.

At step 316, interface 242 of decision engine 150 receives third partydata 160 associated with a request for customer information fromexternal module 250. Third party data 160 is information that can beused to identify a customer, such as an address, telephone number,social security number, or bank account number. Decision engine 150determines whether customer identifier 116 matches third party data 160at step 318.

If customer identifier 116 matches third party data 160, the methodproceeds to step 320. At step 320, interface 242 of decision engine 150communicates customer profile code 140 to third party 162 at acommunication time period. For example, if customer identifier 116 ofcustomer 114 is represented as account number “ABCXYZ”, and third partydata 160 is represented as account number “ABCXYZ”, then customeridentifier 116 matches third party data 160 and interface 242communicates customer 114's profile code 140 to third party 162.Interface 242 of decision engine 150 may communicate a plurality ofcustomer profile codes 140 simultaneously, or decision engine 150 maytransmit each customer profile code 140 separately to third party 162.In certain embodiments, interface 242 of decision engine 150 maycommunicate updated customer profile codes 140 to third party 162. Insome instances, decision engine 150 may communicate customer profilecodes 140 via an API. The communication time period indicates a time orperiodicity to communicate the data. The communication time period canbe a fixed time period, a variable time period, a time period thatoccurs when network resource usage is at a low period, or any indicationof when interface 242 of decision engine 150 should communicate customerprofile code 140.

If decision engine determines customer identifier 116 does not matchthird party data 160 at step 318, then decision engine 150 does notcommunicate customer profile code 140 to third party 162. In someembodiments, processor 244 of decision engine 150 generates a datareport. For example, the data report may state that the third party data160 did not match customer identifiers 116 a-116 n. In some embodiments,interface 242 of decision engine 150 may communicate the data report tothird party 162. The data report may include information such as thenumber of requests for customer information communicated to decisionengine 150 within a period of time, the number of requests processed bydecision engine 150 within a period of time, or the number of matches ornon-matches generated by decision engine 150.

Modifications, additions, or omissions may be made to the methoddepicted in FIG. 3. The method may include more, fewer, or other steps.For example, if customer identifier 116 matches third party data 160,interface 242 of decision engine 150 may communicate one or more rules120 a-120 n to third party 162. As another example, if customeridentifier 116 matches third party data 160, interface 242 of decisionengine 150 may communicate code segments to third party 162 tofacilitate decoding of customer profile code 140. As yet anotherexample, steps may be performed in parallel or in any suitable order.Further, any suitable component of system 200 may perform one or moresteps of the method.

FIG. 4 illustrates an example embodiment of a method for encodingcustomer data 112 according to service levels 113. The method begins atstep 410 where memory 236 stores customer data 112 according to servicelevels 113, as described above. At step 412, memory 236 also storesrules 120. At step 414, one or more components of enterprise 210receives a third party request for customer data 112, such as fromexternal module 250. Execution then proceeds to step 416 where one ormore components of enterprise 210 determines whether the third partythat communicated the request is authenticated. In one example,enterprise 210 signs up third parties to an account with associatedservice levels 113. This account information may be stored as part ofthird party data 160. Then, decision engine 150 determines whether anactive account exists for the third party that communicated the request.If not, then the third party is not authenticated and execution proceedsto step 418 where the third party request is denied and executionsubsequently terminates at step 430. If an active account does exist forthe third party that communicated the request, then the third party isauthenticated and execution proceeds to step 420 where decision engine150 determines the service level 113 of the third party.

At step 422, decision engine retrieves customer data 112 associated withthe service level 113 determined at step 420. At step 424, rules engine110 applies the rules 120 to this customer data 112 to transform thecustomer data 112 into code segments 126, 136, as described above. Atstep 426, rules engine 110 generates a customer profile code 140 basedon the code segments generated at step 424. Interface 232 communicatesthe customer profile code 140 to the third party at step 428 andexecution terminates at step 430.

FIG. 5 illustrates an example embodiment of a method for decodingcustomer data 112 to authenticate a customer 114. This method isperformed by a third party, such as external module 250. The methodbegins at step 510 where external module 250 receives an authenticationrequest for a particular customer 114. As described above, for example,this authentication request may be received in conjunction with anattempt to verify a customer's identity or in conjunction withdetermining whether to extend a line of credit to a customer 114. Atstep 512, external module 250 communicates a request for customer data112 associated with the particular customer 114 to enterprise 210. Atstep 514, external module 250 receives a customer profile code 140associated with the particular customer 114 for whom the request wasmade. The customer profile code 140 is an encoded representation of thecustomer data 112 for the customer 114 and includes one or more codesegments 126, 136. At step 516, external module 250 also receives rules120 associated with the customer profile code 140 received at step 514.At step 518, external module 250 transforms the code segments 126, 136into customer data 112 by applying the rules 120 received at step 516.

Upon transforming the code segments 126, 136 into customer data 112,external module 250 determines whether the customer 114 is authentic atstep 520. For example, external module 250 may receive a customer'sfinancial information to determine whether to extend a line of credit tocustomer 114. Or, it may receive a customer's biographical data toverify the identity of the customer 114. If the customer 114 is notauthenticated at step 520, execution proceeds to step 522 where externalmodule 250 denies the authentication request received at step 510. Ifthe customer 115 is authenticated at step 520, execution proceeds tostep 524 where external module 250 grants the authentication requestreceived at step 510 (e.g., verifies the customer 114 or decides toextend a line of credit to customer 114). Execution terminates at step526.

FIG. 6 illustrates an example embodiment of a method for decodingcustomer data 112 to analyze a geographical area. This method isperformed by a third party, such as external module 250. The methodbegins at step 610 where external module 250 communicates a request forcustomer data 112 to enterprise 210. The request is associated with aparticular geographical area, such as, for example, one or more citiesor zip codes. Thus, the request is for customer data 112 for customers114 in the identified geographical area. Execution proceeds to step 612where external module 250 receives a customer profile code 140associated with the particular customer 114 for whom the request wasmade. The customer profile code 140 is an encoded representation of thecustomer data 112 for the customer 114 and includes one or more codesegments 126, 136. At step 614, external module 250 also receives rules120 associated with the customer profile code 140 received at step 612.At step 616, external module 250 transforms the code segments 126, 136into customer data 112 by applying the rules 120 received at step 614.

Upon transforming the code segments 126, 136 into customer data 112,external module 250 analyzes the geographical area using the customerdata 112 at step 618. In one embodiment, a third party that requeststhis customer data 112 specific to a particular geographic area may useit to analyze the potential market for particular goods and services inthat geographical area. For example, a third party merchant may use thisinformation to determine which additional geographic markets it shouldor should not enter, or which targeted goods or services to offer in aparticular existing geographic market. Execution terminates at step 620.

FIG. 7 illustrates an example embodiment of a method for decodingcustomer data 112 to determine an operations history for a set ofcustomers 114. This method is performed by a third party, such asexternal module 250. The method begins at step 710 where external module250 determines a set of customers 114 to analyze. For example, a thirdparty merchant may determine one or more of its existing or potentialcustomers 114 to analyze. Execution proceeds to step 712, where externalmodule 250 communicates a request for customer data 112 to enterprise210. The request is associated with the subset of customers 114determined at step 710. Execution proceeds to step 714 where externalmodule 250 receives a customer profile code 140 associated with theparticular customers 114 for whom the request was made. The customerprofile code 140 is an encoded representation of the customer data 112for the customers 114 and includes one or more code segments 126, 136.At step 716, external module 250 also receives rules 120 associated withthe customer profile code 140 received at step 714. At step 718,external module 250 transforms the code segments 126, 136, into customerdata 112 by applying the rules 120 received at step 716.

Upon transforming the code segments 126, 136 into customer data 112, atstep 720, external module 250 analyzes customer data 112 to determinesthe operations history for the set of customers determined at step 710.For example, third party merchant may use the customer data 112 receivedgenerated at step 718 to determine the operations history of the set ofcustomers 114 determined at step 710 (e.g., where that set of customers114 spends money to purchase goods and services; how much money that setof customers 114 spends on goods and services; the frequency of spendingfor that set of customers 114; etc.). The third party merchant can thenuse this information to target those locations for its own sales andmarketing. Execution terminates at step 722.

Although the present invention has been described with severalembodiments, a myriad of changes, variations, alterations,transformations, and modifications may be suggested to one skilled inthe art, and it is intended that the present invention encompass suchchanges, variations, alterations, transformations, and modifications asfall within the scope of the appended claims.

To aid the Patent Office, and any readers of any patent issued on thisapplication in interpreting the claims appended hereto, applicants notethat they do not intend any of the appended claims to invoke 35 U.S.C.§112(f) as it exists on the date of filing hereof unless the words“means for” or “step for” are explicitly used in the particular claim.

What is claimed is:
 1. A system for encoding customer data, comprising:a memory operable to store: customer data, wherein some of the customerdata is associated with a first service level and some of the customerdata is associated with a second service level; a first rule comprisinga first plurality of conditions; and a second rule comprising a secondplurality of conditions; a decision engine operable to: receive arequest for customer data from a third party; determine that the thirdparty is associated with the first service level; retrieve the customerdata that is associated with the first service level in response todetermining that the third party is associated with the first servicelevel; a rules engine operable to: transform a first portion of theretrieved customer data into a first code segment by applying the firstrule and by satisfying a condition of the first plurality of conditionsof the first rule; transform a second portion of the customer data intoa second code segment by applying the second rule and by satisfying acondition of the second plurality of conditions of the second rule; andcombine at least the first code segment and the second code segment toform a customer profile code; and an interface engine communicativelycoupled to the rules engine and operable to communicate the customerprofile code to the third party.
 2. The system of claim 1, wherein theinterface engine is further operable to: communicate the first rule andthe second rule to the third party; and communicate the first codesegment and the second code segment to the third party to facilitatedecoding of the customer profile code.
 3. The system of claim 1, whereinthe interface engine is further operable to receive third party datafrom the third party.
 4. The system of claim 3, wherein the third partydata is a phone number, an email address, or an account number.
 5. Thesystem of claim 1, wherein the interface engine communicates thecustomer profile code to the third party by granting the third partyaccess to the customer profile code via an application programminginterface (API).
 6. The system of claim 1, wherein: the customer datacomprises a first customer parameter and a second customer parameter;each of the plurality of first conditions of the first rule isassociated with the first customer parameter; each of the plurality ofsecond conditions of the second rule is associated with the secondcustomer parameter; applying the first rule comprises analyzing thefirst customer parameter against the first customer parameterconditions; and applying the second rule comprises analyzing thecustomer's birth year against the second customer parameter conditions.7. The system of claim 1, wherein the customer profile code isassociated with a customer identifier that comprises the customer'sphone number, the customer's email address, or the customer's accountnumber.
 8. The system of claim 1, wherein the customer profile code isan alphanumeric code.
 9. A system, comprising: a memory that is operableto store customer data, third party data, and one or more rules, each ofthe one or more rules comprising at least one condition, wherein some ofthe customer data is associated with a first service level and some ofthe customer data is associated with a second service level; a processorthat is communicatively coupled to the memory and operable to: receive arequest for customer data from a third party; determine that the thirdparty is associated with the first service level; retrieve the customerdata that is associated with the first service level in response todetermining that the third party is associated with the first servicelevel transform at least a portion of the retrieved customer data into acustomer profile code by applying the one or more rules and bysatisfying the at least one condition of each of the one or more rules;and an interface communicatively coupled to the processor and operableto communicate the customer profile code to the third party.
 10. Thesystem of claim 9, wherein the interface is further operable tocommunicate the one or more rules to the third party to facilitatedecoding of the customer profile code.
 11. The system of claim 9,wherein the interface is further operable to receive third party datafrom the third party.
 12. The system of claim 11, wherein the thirdparty data is a phone number, an email address, or an account number.13. The system of claim 9, wherein the interface communicates thecustomer profile code to the third party by granting the third partyaccess to the customer profile code via an application programminginterface.
 14. The system of claim 9, wherein the customer profile codeis associated with a customer identifier that comprises the customer'sphone number, the customer's email address, or the customer's accountnumber.
 15. The system of claim 9, wherein the customer profile code isan alphanumeric code.
 16. A method, comprising: storing customer data,wherein some of the customer data is associated with a first servicelevel and some of the customer data is associated with a second servicelevel; storing a first rule comprising a first plurality of conditions;storing a second rule comprising a second plurality of conditions;receiving a request for customer data from a third party; determiningthat the third party is associated with the first service level;retrieving the customer data that is associated with the first servicelevel in response to determining that the third party is associated withthe first service level; transforming a first portion of the retrievedcustomer data into a first code segment by applying the first rule andby satisfying a condition of the first plurality of conditions of thefirst rule; transforming a second portion of the customer data into asecond code segment by applying the second rule and by satisfying acondition of the second plurality of conditions of the second rule;combining at least the first code segment and the second code segment toform a customer profile code; and communicating the customer profilecode to the third party.
 17. The method of claim 16, further comprising:communicating the one or more rules to the third party; andcommunicating the one or more code segments to the third party tofacilitate decoding of the customer profile code.
 18. The method ofclaim 16, wherein the communicating the customer profile code to thethird party is performed using an application programming interface(API).
 19. The method of claim 16, wherein the customer profile code isassociated with a customer identifier that comprises the customer'sphone number, the customer's email address, or the customer's accountnumber.
 20. The method of claim 16, wherein the customer profile code isan alphanumeric code.